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Prototype  Real-Time  Monitor:  Requirements 

Abstract.  ^The  requirements  imposed  by  flight  simulators  and  good  software  engi¬ 
neering  practice  on  Ada91  systems  force  software  engineers  to  seek  new  solutions  to 
the  problem  of  monitoring  executing  software.  This  report  examines  some  of  these 
requirements  and,  based  on  these  requirements,  defines  a  subset  for  implementation 
as  a  prototype  real-time  monitor  (RTM). 


Preface 

Intended  Audience 

This  document  is  intended  to  be  read  and  used  by  systems  engineering  professionals  to  design 
and  produce  a  real-time  monitor  package  that  meets  all  of  the  requirements  stated  in  this  report. 

Associated  Documents 

•  Prototype  Real-Time  Monitor:  Executive  Summary  [V an  Scoy  87a] 

•  Prototype  Real-Time  Monitor:  Design  [Van  Scoy  87b] 

•  Prototype  Real-Time  Monitor:  User's  Manually  an  Scoy  87c] 

•  Prototype  Real-Time  Monitor:  Ada  Code  [Van  Scoy  87d] 

Context  of  Report 

The  prototype  RTM  in  this  report  was  built  to  address  two  specific  technical  questions  raised  by 
the  Ada  Simulator  Validation  Program  (ASVP)  contractors: 

1 .  How  can  user  toots  find,  access,  and  display  data  hidden  in  the  bodies  of  Ada 
applications? 

2.  How  can  user  tools  be  layered  on  top  of  Ada  applications? 

The  prototype  is  documented  by  this  report  because  the  ASVP  contractors  needed  a  monitor  tool, 
but  did  not  have  the  contract  resources  to  develop  one.  The  prototype  RTM  is  intended  to  be  a 
simple  tool  that  is  easily  rehosted  and  extended.  It  is  not  intended  to  be  an  example  of  what  a 
well-documented  system  should  include.  Since  it  was  a  prototyping  effort,  no  standard  documen¬ 
tation  or  development  methods  were  applied.  Also,  we  did  not  attempt  to  solve  all  the  traditional 
"monitor"  problems. 


’Ada  to  a  registered  trademark  of  the  U  S  Government  (Ada  Joint  Program  Office) 
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1.  User’s  Problem  Statement 


There  is  a  large  class  of  computer  programs  that  run  in  real  time  and  are  used  to  control  mechan¬ 
ical  apparatus.  These  programs  are  generally  characterized  by  some  sort  of  high-speed  signal 
transfer  interlace  to  transmit  and  obtain  signals  from  the  real  world  apparatus  that  is  being  con¬ 
trolled.  it  is  the  nature  of  these  programs  that  they  must  be  capable  of  reacting  to  and  providing 
the  real  world  stimuli  without  interruption  or  pause,  or  data  may  be  lost.  This  could  result  in  errors 
in  the  control  of,  or  the  possible  destruction  of,  the  real  world  apparatus. 

One  of  the  problems  associated  with  this  specific  class  of  computer  programs  is  obtaining  ac¬ 
curate  information  about  the  internal  states  of  the  controlling  algorithms.  There  are  two  reasons  to 
require  this  information:  The  first  is  to  obtain  enough  information  to  be  able  to  evaluate  the 
performance  of  the  process  controller.  Sometimes  this  investigative  process  is  more  effectively 
carried  out  in  real  time  while  the  system  is  active.  Other  times,  a  stored  record  of  pertinent 
internal  state  data  is  required.  The  second  reason  is  to  be  able  to  do  dynamic  adjustment  of  the 
process-control  parameters.  This  is  difficult  because  any  attempt  to  add  the  extra  workload  of 
having  the  program  report  status  to  an  external  observer  may  introduce  delays  in  the  control 
algorithms,  which  may  have  the  undesired  effect  of  changing  the  state  during  the  measurement. 

Ada  programs  used  for  real-time  simulation  are  a  particular  class  of  computer  programs  of  inter¬ 
est.  Monitoring  these  programs  is  difficult  because  well-engineered  Ada  programs  enforce  the 
general  principle  of  information  hiding:  that  is,  modules  within  the  program  generally  have  access 
to  state  information  about  other  modules  only  on  a  need-to-know  basis.  This  makes  it  very  difficult 
to  introduce  into  the  system  a  monitoring  device  that  is  capable  of  making  visible  (to  an  external 
observer)  state  information  that  is  well  hidden  due  to  the  lack  of  a  universal  repository  of  such 
information.  To  further  compound  the  problem,  the  real-time  nature  of  the  program  virtually  as¬ 
sures  that  the  internal  states  are  constantly  changing  except  for  a  few  systems  whose  real-world 
response  is  extremely  slow  relative  to  the  computer  cycle  time. 

What  is  needed,  then,  is  a  software-state  monitoring  method  that  takes  the  dynamic  nature  of  the 
system  into  account  while  producing  state  information  for  external  display.  The  monitor,  while 
extracting  the  information,  must  not  introduce  undue  changes  in  the  nature  of  the  system  being 
monitored,  and  it  must  produce  the  information  in  a  timely  enough  fashion  to  be  still  meaningful 
and  useful  to  the  observer.  It  is  important  for  the  observer  to  be  able  to  select  the  categories  and 
particulars  of  the  state  information  and  process-controlling  parameters  to  be  monitored  and  for 
the  observer  to  be  able  to  maintain  running  histories  of  the  information  for  further  off-line  study  of 
the  system.  It  is  also  important  to  be  able  to  make  timely  changes  in  the  process-controlling 
parameters  to  adjust  the  processes  effectively. 
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2.  Requirements  Analysis 

To  obtain  a  clearer  understanding  of  the  needs  and  wants  of  the  user,  it  is  necessary  to  elaborate 
on  the  problem  definition  provided  by  the  user.  This  is  an  appropriate  step  in  that  it  allows  the 
designer  to  clarify  key  points  in  the  user's  problem  statement.  Once  the  designer  has  presented 
an  interpretation  of  the  problem,  a  dialogue  with  the  user  can  begin,  and  points  of  contention  and 
misunderstanding  can  be  resolved  in  an  interactive  process.  To  achieve  these  ends,  the  follow¬ 
ing  paragraphs  extract  important  phrases  from  the  user's  problem  statement  starting  on  page  3, 
denote  them  with  bold  and  italicized  text,  and  add  additional  detail  based  on  the  experience  and 
understanding  the  designer  brings  to  the  problem. 

To  begin  with,  the  user  has  stated  that  a  software-state  monitoring  method  is  needed  in  this 
problem  domain.  A  requirement  of  such  a  monitor  is  that  it  extract  state  information  and  update 
process-control  parameters  at  a  periodic  rate.  This  periodic  rate  will  be  under  user  control  so  that 
the  monitor  can  fit  into  any  desired  timing  pattern. 

Since  both  state  Information  and  process-control  parameters  are  embodied  by  Ada  variables, 
all  Ada  data  types  except  the  following  shall  be  accessible  via  the  monitor: 

•  access  type  variables2 

•  task  type  variables 

Finally,  given  the  critical  nature  of  some  state  Information  and  process-control  parameters, 
the  user  will  have  the  ability  to  protect  information  (from  modification  via  the  monitor)  by  desig¬ 
nating  it  as  read-only  or  unprotect  it  by  designating  it  as  read/write  (which  is  the  default  status  of 
all  information). 

The  external  display  will  be  a  video  display  terminal  (VDT)  dedicated  to  monitoring  use  during 
the  active  participation  of  the  monitor. 

When  the  user  requests  that  the  monitor  must  not  Introduce  undue  changes  In  the  nature  of 
the  system  being  monitored,  this  dictates  that  the  active  participation  of  the  monitor  must  not 
adversely  affect  the  timing  of  the  monitored  system. 

To  be  able  to  produce  the  Information  In  a  timely  enough  fashion  for  It  to  be  still  mean¬ 
ingful  and  useful  is  critical  to  the  usability  of  the  monitor.  Failure  to  achieve  this  is  a  failure  of 
the  monitor  as  a  whole.  To  achieve  this,  the  monitor  is  obliged  to  extract  as  much  information  as 
possible  from  the  monitored  program  during  its  period  of  active  execution.  If  the  monitor  cannot 
process  all  the  user's  commands  in  a  given  time  period,  it  must  identify  to  the  user  those  actions 
that  were  not  processed. 

A  key  function  from  the  user  standpoint  is  the  ability  to  select  the  categories  and  particulars  of 
the  state  Information  and  the  process-control  parameters.  Under  the  heading  of  categories, 
the  user  will  be  able  to  : 


*7he  object*  accessed  are  monitored;  access  values  (i.e.,  addresses)  are  not. 
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•  Select  the  state  information  for  display. 

•  Select  the  process-control  parameters  for  display. 

•  Select  the  state  information  for  history  recording. 

•  Select  the  process-control  parameters  for  history  recording. 

Under  the  heading  of  particulars,  the  user  will  be  able  to: 

•  Format  the  display. 

•  Format  the  state  information  and  process-control  parameters.  Specifically,  the  user 
will  be  able  to  define  (for  each  monitored  item): 

•  units  (such  as  meters,  feet,  etc.) 


'  numeric  representation  (binary,  octal,  decimal,  hexadecimal,  scientific  nota¬ 
tion,  engineering  notation,  floating  point,  fixed  point) 


rate  at  which  the  display  is  updated 
rate  at  which  the  history  is  updated 


The  ability  to  maintain  running  histories  requires  that  the  monitor  be  able  to  save  state 
Information  and  process-control  parameters  to  a  permanent  storage  device  and  to  provide  a 
mechanism  for  retrieving  that  history  at  a  later  time. 


Finally,  the  ability  to  make  timely  changes  In  the  process-controlling  parameters  requires  that 
the  user  be  able  to  select  which  items  to  adjust  and  that  the  application  of  any  given  set  of 
adjustments  be  under  the  user’s  control  and  occur  at  a  known,  predictable  time  and  in  a  deter¬ 
ministic  manner. 
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3.  Designer’s  Problem  Statement 

The  problem  statement  presented  here  contains  four  sections: 

1.  Definitions  of  Terms:  terms  whose  meanings  are  specific  to  the  context  of  this 
report. 

2.  User’s  Needs:  essentially  a  recasting  of  the  user's  problem  statement  in  technical 
terms,  with  no  added  content. 

3.  Designer’s  Technical  Program-Related  Additions:  statements  that  come  from 
the  designer's  body  of  expert  knowledge  and  consist  of  additions  of  technical  con¬ 
tent  related  to  the  problem. 

4.  External  Considerations:  considerations  either  of  a  technical  or  non-technical,  but 
not  problem-related,  nature. 

The  statements  in  this  chapter  represent  the  top-level  framework  for  the  solution  and  are  ap¬ 
proved  by  the  user. 


3.1.  Definitions  of  Terms 

The  following  terms  have  special  meaning  within  the  context  of  this  document: 

Flight  simulator.  The  hardware  and  software  packages  exclusive  of  the  monitor,  used 
to  implement  and  control  the  simulated  aircraft. 

Monitor.  The  software  package  (also  referred  to  as  the  RTM)  to  be  used  on  the  flight 
simulator  computer  to  obtain,  store,  and  display  system-state  information  to  the  user. 

Process-controlling  parameters.  Internally  stored  coefficients  that  are  used  in  the 
control  loop  equations  to  determine  the  feedback  amounts  and  system  outputs  of  the 
flight  simulator. 

State  Information:  The  values  of  internally  generated  and  stored  numbers  that  repre¬ 
sent  the  flight  simulator  inputs,  outputs,  or  intermediate  results  of  calculations  used  to 
determine  them. 

User.  The  person  operating  and  directing  the  monitor  to  obtain,  present,  and  modify 
the  flight  simulator  state  information  and  process-controlling  parameters.  The  user  is 
not  the  instructor  or  trainee  who  use  the  flight  simulator  software. 


3.2.  User’s  Needs 

1 .  The  monitor  will  be  capable  of  extracting  all  flight  simulator  information  that  is  inter¬ 
nally  represented  as  Ada  variables  and  provide  within  the  monitor  a  flexible  means 
to  display  that  information  on  a  video  display  terminal. 

2.  The  monitor  will  be  integrated  into  the  flight  simulator  software  so  that  its  use  will 
not  degrade  the  normal  operations  of  the  flight  simulator. 

3.  The  monitor  will  have  user-selectable  flight  simulator  information  extraction  and  dis¬ 
play  rates. 

4.  The  monitor  will  have  user-selectable  display  formats  for  the  flight  simulator  infor¬ 
mation,  with  display  storage  and  recall. 
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5.  The  monitor  will  have  user-modifiable  values  for  the  process-controlling 
parameters.  These  modifications  will  become  effective  only  in  a  predictable  and 
deterministic  manner. 


3.3.  Designer’s  Technical  Problem-Related  Additions 

6.  The  monitor  will  be  written  in  the  Ada  programming  language. 

7.  The  monitor  will  be  compatible  with  and  function  with  the  flight  simulators  of  the  two 
ASVP  contractors  (i.e.,  Boeing  and  Burtek).  This  means  that  the  monitor  must  be 
capable  of  being  compiled,  loaded,  and  executed  with  both  systems. 

8.  The  monitor  will  prohibit  the  Ada  access3  and  task  type  variables  from  being  ac¬ 
cessible  to  the  monitor.  We  will  also  prohibit  the  Ada  object  constant  from  modifi¬ 
cation,  as  it  cannot  be  changed  after  initialization. 


3.4.  External  Considerations 

9.  The  monitor  will  use  good  software  engineering  principles  and  produce  a  well- 
documented,  extensible,  modular,  and  maintainable  system.4 


*The  objects  accessed  are  monitored;  access  values  (i.e..  addresses)  are  not 

4That  is,  as  long  as  these  requirements  do  not  conflict  with  the  prototype  nature  of  the  development 
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4.  Real-Time  Monitor  Requirements 

This  chapter  sets  forth  the  requirements  for  a  real-time  monitor  package  (the  monitor)  that  will  be 
integrated  into  a  hardware/software  system  used  as  an  aircraft  trainer/flight  simulator.  This  pack¬ 
age  will  be  used  to  provide  system  state  infoimation  to  the  user  for  the  purposes  of  monitoring, 
recording,  and  adjusting  the  performance  of  the  flight  simulator  software.  While  the  contents  ot 
this  document  are  believed  to  be  logically  consistent  and  sufficient  to  describe  the  required  opera¬ 
tion  of  the  monitor,  no  guarantee  of  completeness  is  made. 

The  top-level  requirements  for  the  system  are  derived  in  Chapter  3,  Designer’s  Problem  State¬ 
ment.  The  system  is  composed  of  the  three  major  system  objects:  the  user,  the  monitor,  and 
the  flight  simulator.  There  are  three  possible  interfaces  for  information  exchange  among  the 
three  objects.  The  interface  between  the  user  and  the  monitor  is  characterized  by  the  User's 
Manual  (Van  Scoy  87c).  The  interface  between  the  monitor  and  the  flight  simulator  is  charac¬ 
terized  by  the  System  Interface  Manual .5  The  third  interface  is  between  the  user  and  the  flight 
simulator  and  is  not  a  part  of  this  problem. 


4.1.  User  Interface  Requirements 

The  requirements  for  the  monitor  were  extracted  during  the  composition  of  the  User's  Manual  and 
the  System  Interface  Manual.  A  reading  of  the  user's  needs  (Section  3.2,  paragraphs  3, 4,  and  5) 
yields  the  following  user-controlled  actions: 

R1 .  Activate  the  monitoring  process. 

R2.  Deactivate  the  monitoring  process. 

R3.  Select  the  information  to  be  extracted  for  display. 

R4.  Select  the  rate  that  information  is  extracted. 

R5.  Select  the  format  of  the  displayed  information  in  advance. 

R6.  Select  the  format  of  the  displayed  information  on  demand. 

R7.  Initiate  the  display  of  extracted  information. 

R8.  Terminate  the  display  of  extracted  information. 

R9.  Cause  a  display  to  be  permanently  stored. 

RIO.  Cause  a  stored  display  to  be  recalled  for  viewing. 

R1 1 .  Cause  new  values  to  be  entered  for  process-controlling  parameters. 


A  reading  of  the  designer-imposed  additions  in  Section  3.3,  paragraph  7,  gives  the  following 
additional  user-controlled  actions: 

R12.  Transfer  the  monitor  software  package,  including  libraries,  to  the  target  hardware  and 
compile  it  there. 


i  - 

*The  System  Interlace  Manual  is  the  Ada  package  specification  of  the  Rtmjcore. 

* 
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R13.  Provide  and  connect  any  special  monitor  hardware  to  the  target  hardware. 

R1 4.  Load  the  monitor  package  together  with  the  flight  simulator  package  on  the  target 
hardware. 

R1 5.  Initiate  the  execution  o!  the  combined  system. 

4.2.  System  Interface  Requirements 

A  reading  of  the  user's  needs  in  Section  3.2,  paragraphs  1  and  2,  yields  the  following  system- 
controlled  actions: 

R16.  Extract  the  value  of  flight  simulator  Ada  variables  at  the  monitor's  request. 

R1 7.  Service  the  monitor's  requests  to  translate  information  for  the  monitor's  VDT. 

R18.  Provide  the  necessary  computing  and  memory  resources  to  the  monitor  from  spare 
capacity. 

R19.  Do  not  degrade  the  normal  operational  performance  of  the  flight  simulator. 

A  reading  of  the  designer-imposed  additions  in  Section  3.3,  paragraphs  6  and  8,  give  the  follow¬ 
ing  additional  monitor-controlled  actions: 

R20.  Refuse  the  request  to  extract  flight  simulator  Ada  variables  if  they  are  of  task  type. 

R21 .  Refuse  the  request  to  modify  flight  simulator  Ada  objects  if  they  are  of  constant  type. 

R22.  Extract  objects  referenced  when  requested  to  extract  Ada  access  type  objects. 

4.3.  General  Requirements 

A  reading  of  the  external  considerations  in  Section  3.4,  paragraph  9,  and  the  designer  imposed 
additions  in  Section  3.3,  paragraph  6,  gives  an  extensive  set  of  general  requirements.  Some  of 
these  apply  to  the  production  of  the  code  and  documents;  others  apply  to  the  design  and  imple¬ 
mentation  of  the  system. 

R23.  Handle  imperfect  inputs  in  a  reasonable,  graceful  manner. 

R24.  Implement  the  monitor  in  Ada. 

R25.  Develop  a  well-engineered  monitor. 

R26.  Develop  an  extensile  monitor. 

R27.  Develop  a  modular  monitor. 

R28.  Develop  a  maintainable  monitor. 

R29.  Develop  a  well-documented  monitor. 


5.  Prototype  Requirements 

Given  the  context  of  the  real-time  monitor  described  in  the  the  Real-Time  Monitor:  Executive 
Summary  p/ an  Scoy  87a],  certain  restrictions  were  imposed  on  the  requirements  presented  in 
Chapter  4.  These  restrictions  were  imposed  to  limit  the  size  of  the  effort  (because  of  time  and 
staffing  constraints)  and  to  restrict  the  scope  of  the  task  to  the  technically  challenging  areas. 
While  these  restrictions  limit  the  functionality  of  the  prototype  developed,  the  requirements  imple¬ 
mented  still  represent  a  meaningful  and  useful  subset. 

To  develop  a  useful  prototype,  the  requirements  were  divided  into  four  classes: 

•  fully  implemented  by  the  prototype 

•  partially  implemented  by  the  prototype 

•  fully  implemented  by  the  user  of  the  prototype 

•  not  implemented 

Each  requirement  class  is  delineated  below. 


5.1.  Fully  Implemented  Requirements 

These  requirements  are  fully  implemented  by  the  prototype  RTM.  They  were  chosen  because 
they  represent  a  useful  subset  of  the  full  system  functionality  and  form  the  basis  upon  which 
extensions  can  be  built. 

R 1 .  Activate  the  monitoring  process. 

R2.  Deactivate  the  monitoring  process. 

R4.  Select  the  rate  at  which  information  is  extracted. 

R7.  Initiate  the  display  of  extracted  information. 

R8.  Terminate  the  display  of  extracted  information. 

R1 6.  Extract  the  value  of  flight  simulator  Ada  variables  at  the  monitor’s  request. 

R17.  Service  the  monitor’s  requests  to  translate  information  for  the  monitor's  VDT. 

R20.  Refuse  the  request  to  monitor  flight  simulator  Ada  variables  if  they  are  of  task  type. 

R21 .  Refuse  the  request  to  modify  flight  simulator  Ada  objects  if  they  are  of  constant  type. 
R22.  Extract  objects  referenced  when  requested  to  extract  Ada  access  type  objects. 

R23.  Handle  imperfect  inputs  in  a  reasonable,  graceful  manner. 

R24.  Implement  the  monitor  in  Ada. 

R25.  Develop  a  well-engineered  monitor. 

R26.  Develop  an  extensible  monitor. 

R27.  Develop  a  modular  monitor. 

R28.  Develop  a  maintainable  monitor. 

R29.  Develop  a  well  documented  monitor. 
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5.2.  Partially  Implemented  Requirements 

These  requirements  contribute  to  the  baseline  functionality  of  the  monitor,  but  are  restricted  to 

limit  the  scope  of  the  implementation  (i.e.,  items  of  the  "belt  and  whistle’  variety  were  deliberately 

excised  from  the  requirements).  The  requirements  are  listed,  with  the  restrictions  shown  in  italics. 

R3.  Select  the  information  to  be  extracted  for  display:  not  all  the  variables  in  the  flight  simu¬ 
lator  are  available,  as  noted  elsewhere,  but  additional  restrictions  depend  on  the  sophis¬ 
tication  of  the  address  generation  scheme  used  by  the  implementation  (see  the  Proto¬ 
type  Real-Time  Monitor:  Design  [Van  Scoy  87b]  for  additional  information). 

R5.  Select  the  format  of  the  displayed  information  in  advance:  decimal  output  for  integers 
and  scientific  notation  for  floats;  no  other  notations  (octal,  binary,  etc.). 

R6.  Select  the  format  of  the  displayed  information  on  demand:  see  restrictions  for  previous 
requirement. 

R11.  Cause  new  values  to  be  entered  for  process-controlling  parameters:  only  variables 

which  are  accessible  can  be  modified,  see  above  restrictions  on  accessibility,  and  then 
only  using  values  that  are  compatible  with  the  Ada  type  of  the  variable. 

R12.  Transfer  the  monitor  software  package,  including  libraries,  to  the  target  hardware  and 
compile  it  there:  system  dependencies  were  removed  wherever  possible  and  isolated 
when  necessary. 


5.3.  User-Implemented  Requirements 

These  requirements  are  imposed  on  the  user  because  they  represent  system  level  needs  about 

which  the  monitor  has  no  knowledge: 

R12.  Transfer  the  monitor  software  package,  including  libraries,  to  the  target  hardware  and 
compile  it  there. 

R14.  Load  the  monitor  package  together  with  the  flight  simulator  package  on  the  target 
hardware. 

R1 5.  Initiate  the  execution  of  the  combined  system. 

R18.  Provide  the  necessary  computing  and  memory  resources  from  spare  capacity  to  the 
monitor. 

R19.  Do  not  degrade  the  normal  operational  performance  of  the  flight  simulator: 


5.4.  Unimplemented  Requirements 

These  requirements  are  not  implemented  because  they  are  extensions  to  the  baseline  require¬ 
ments  established  above. 

R9.  Cause  a  display  to  be  permanently  stored. 

RIO.  Cause  a  stored  display  to  be  recalled  for  viewing. 

R13.  Provide  and  connect  any  special  monitor  hardware  to  the  target  hardware. 
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